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Abstract. Any CNF formula can be decomposed two blocked subsets 
such that both can be solved by BCE (Blocked Clause Elimination). To 
make the decomposition more useful, one hopes to have the decomposi¬ 
tion as unbalanced as possible. It is often time consuming to achieve this 
goal. So far there have been several decomposition and post-processing 
algorithms such as PureDecompose, QuickDecompose, EagerMover etc. 
We found that these existing algorithms are often either inefficient or low- 
quality decomposition. This paper aims at improving the decomposition 
quality, while keeping the runtime of algorithms under control. To achieve 
this goal, we improve the existing BCE, and present two new variants 
of PureDecompose, a new heuristic decomposition called Lesslnterfere- 
Decompose, and a new post-processing algorithm called RsetGuidedDe- 
compose. Combining these new techniques results in a new algorithm 
called MixDecompose. In our experiments, there is no application for¬ 
mula where the quality of PureDecompose+EagerMover is better than 
MixDecompose. In terms of speed, MixDecompose is also very fast. Our 
average runtime is a little longer, but the worst-case runtime is shorter. 
In theory, our two variants of PureDecompose requires linear time in the 
number of clauses. By limiting the size of the touch list used by BCE, 
we can guarantee always that MixDecompose runs in linear time. 

Keywords: Blocked Clause Elimination, Blocked Clause Decomposi¬ 
tion, Tool for CNF preprocessing 


1 Introduction 

Recently, one found that blocked clause decomposition (BCD) can not only 
efficiently find backbone variables [T] and implied binary equivalences through 
SAT sweeping, but also improve the performance of the state-of-the-art SAT 
solvers such as Lingeling on hard application benchmarks m- From our 
experimental result of solver abcdSAT m. winner of the main track of SAT 
Race 2015, abcdSAT with BCD was better than abcdSAT without BCD. This 
shows further that BCD is a useful technique. Now many researchers have been 
attracted to pay attention to this subject. 

A set of clauses is said to be a blocked set if it can be removed completely by 
Blocked Clause Elimination (BCE) [516] . Any CNF formula can be decomposed 
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into two blocked subsets. To make a blocked clause decomposition more useful, 
one wants always to have two blocked subsets as unbalanced as possible. The 
problem is that it is not easy to find the most unbalanced subsets. In theory, 
one has proven that finding a maximal blocked subset of a CNF formula with 
the largest cardinality {MaxBS for short) is NP-hard [3]. In other words, it is 
impossible to find the best decomposition in polynomial time unless P = NP. 
So far a few decomposition algorithms were proposed. However, no algorithm 
achieves optimization in all terms. PureDecompose [3] is the fastest, but its 
quality is poor. To improve the quality, Heule et al |3] presented QuickDecom- 
pose. However, QuickDecompose is time-consuming. Soon after, to improve the 
speed, Balyo et al [4] developed a post-processing algorithm called EagerMover. 
Through an exhaustive series of experiments, we noted that although the de¬ 
composition quality of PureDecompose+EagerMover {PureEager for short) and 
QuickDecompose can outperform PureDecompose, their quality is not high yet. 

This paper aims at improving the decomposition quality, while keeping the 
runtime of algorithms under control. To achieve this goal, we present two new 
variants of PureDeeompose, a new decomposition algorithm based on clause cor¬ 
relation degree, and a new post-processing algorithm. In addition, we improve 
the existing BCE to speed up the decomposition. The algorithm resulting from 
integrating these new techniques is called MixDecompose, which can improve 
significantly the quality of decomposition. On application instances, the decom¬ 
position quality of MixDecompose is better than that of PureEager. There is 
no application formula where the quality of PureEager is better than MixDe¬ 
compose. In terms of speed, MixDecompose is still fast. On average, it took 8.97 
seconds on our machine, which is a little slower than PureEager which took 7.41 
seconds. However, in the worst case, MixDecompose was faster than PureEager. 
The latter exceeded 300 seconds in some cases, whereas the former took at most 
110 seconds. 


2 Preliminaries 

In this section, we present basic concepts that will be used in subsequent algo¬ 
rithms for blocked clause decomposition. 

CNF. It is short for conjunctive normal form. A formula in CNF is formulated 
as a conjunction of clauses, where each clause is a disjunction of literals, each 
literal being either a Boolean variable or its negation. The negation of a variable 
X is denoted by x or -^x. In general, a clause C is written as C = xi V • ■ • V Xmj 
where Xi{l < i < m) is a literal. A formula F is written as F = Ci A • • • A Cn, 
where C'i(l < i < n) is a clause. The symbols var{F) and lit{F) denote the sets 
of variables and literals occurring in a formula F, respectively. 

Resolution. Given two clauses Ci = 1 V oi V • • • V Om and C 2 = Tv &i V • ■ • V 6„, 
the clause C = oi V • • • V Om V 61 V ■ • • V 6 „ is called the resolvent of Ci and C 2 
on the literal I, which is denoted by C = C'i( 8 >;C' 2 . 
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Blocked Clauses.Given a CNF formula F, a clause C, a literal I G C is said 
to block C w.r.t. F if (i) C is a tautology w.r.t. or (ii) for each clause C € F 
with I G C, C'®iC is a tautology. A clause is a tautology if it contains both x 
and X for some variable x. When I blocks C w.r.t. F, the literal I and the clause 
C are called a blocking literal and a blocked clause, respectively. 

BCE. It is short for blocked clause elimination, which removes blocked clauses 
from CNF formulas. By BCE(F) we mean the CNF formula resulting from 
repeating the following operation until fixpoint: If there is a blocked clause C € F 
w.r.t. F, let F := F — {C}. It is said that BCE can solve a formula F if and 
only if BCE(F) = 0. The seminal work in BCE is due to Kullmmann [5]. 

3 Blocked Clause Decomposition 

In theory, any CNF formula can be decomposed into two blocked subsets. How¬ 
ever, not all the decompositions are effective. In general, The larger one of the 
blocked sets is, the better the decomposition quality is, since the larger it is, 
the more it resembles the original formula. Therefore, the size difference of the 
two sets is considered as a measure of the decomposition quality. Nevertheless, 
computing the largest blocked set from a CNF formula is NP-hard. Hence, we 
here aim at finding a fast decomposition with higher quality, rather than the 
highest quality. 

This paper improves pure decomposition by defining two possible variable 
ordering for variable elimination. The version based on the ordering from the 
lowest occurrences to the highest is called min pure decomposition. The version 
based on the opposite ordering is called max pure decomposition. In addition, we 
present a simple and limited BCE and a new decomposition algorithm, based 
on this BCE. This new decomposition algorithm is called less interfere decom¬ 
position. To improve further the quality of decomposition, we propose a new 
post-processing called right set guided decomposition. We do not know before¬ 
hand which one of these algorithms is the best. However, since these algorithms 
are lightweight, running all of them one after the other is fast still. We can obtain 
a fast and high-quality algorithm called MixDecompose by integrating sequen¬ 
tially them. In subsequent subsections, we introduce these algorithms one by 
one. 

3.1 Pure Decomposition 

This is viewed as the simplest decomposition algorithm. Here we call it PureDe- 
compose for short. Fig. I shows its basic idea. Let the symbols L and R denote 
the left{large) subset and the right (remainder) subset, respectively. For each 
variable x, this algorithm adds always the larger of F^ and F^ to L and the 
smaller to R, where F^ (F®) is the set of clauses of F where x occurs posi¬ 
tively (negatively). At the termination of this algorithm, we have F = L U R 
with \L\ > \R\. In Fig. 1, maxlF^,, F^} means the set with the larger cardinality 
between F^ and Fj. 
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The advantage of this algorithm is that it can be easily implemented to run 
in linear time in the size of F, using a standard structure of occurrence lists. 
Therefore it is very fast. The drawback is that its decomposition quality is not 
high on many formulas. For this reason, next we improve it by defining two 
possible variable ordering for variable elimination. 

PureDecompose{F) 

L ;=0 

for each variable x € var{F) do 
L := L(J mcix{Fj:, F^} 

F:=F-{F^U F-^) 

return L. 

Fig. 1. Pseudo-code of PureDecompose algorithm 


3.2 Min Pure Decomposition 

By a few empirical observations, we found that the performance of PureDecom¬ 
pose rely significantly on the order in which variables are eliminated. Here, we 
present the first variant of PureDecompose, which is called min pure decomposi¬ 
tion. Fig. 2 shows its pseudo-code. Its variable elimination order is different from 
PureDecompose. One fifth of variable eliminations are to be eliminated in the 
same order as PureDecompose. The remaining variables are to be eliminated in 
order from the lowest occurrence of literals to the highest. If there are multiple 
literals with the lowest occurrence, the literal with the minimum total number 
of clauses containing it is eliminated first. The total clause size of a literal x can 
be formulated as 1 ^ 1 - 

MinPureDecompose{F) 

L — 0 
fc := 0 

while F 7 ^ 0 do 

if k mod 5 = 0 then select u € vars{F) in the order of variable No. 
else m = min„,giit(F) \Fx\ 

u := argmm|j,^l=„X]cGF„ |C| 

L := LU ma.x{Fi,,Fu} 

F:=F-{FuU Fu) 
k := k -\- 1 
return L. 

Fig. 2. Pseudo-code of MinPureDecompose algorithm 

Compared to PureDecompose, this algorithm adds only the search of variables 
to be eliminated. This search can be done in 0{n log n) time, using an order heap, 
where n is the number of variables. In the actual implementation, the number 7 
of variables for computing mina;gHt(F) \Fx\ is limited to 30000 when n < 70000, 
1500 otherwise. That is, the computation of m in Fig. 2 is replaced with m = 
mina,<„/\s<a;<s_|_.^ min{|i7c|, |Fs|}, where s is the previous literal u with the lowest 
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occurrence in the given range. This limit can guarantee that MinPureDecompose 
is still very fast even if n is very large. In terms of decomposition quality, this 
algorithm is superior to the other algorithms on some application instances such 
as ctL4291-567-5-unsat_pre. 

3.3 Max Pure Decomposition 

Now we consider the second variant of PureDecompose. The order of its variable 
eliminations is opposite to that of the first variant. We call this variant max pure 
decomposition^ which is shown in Fig. 3. It always eliminate first a literal with 
the highest occurrence. When multiple literals have the same highest occurrence, 
we select a variable with the lowest difference of its two literal occurrences. 
This can be done by computing min|^^|^,.„ ||F!j;| — |Fs||, where m is defined 
as \Fx\- Actually, the first variant can introduce also this tie-break 

method. 

MaxPureDecompose{F) 

L — 0 

while F ^ do 

m := max„,giit(F) |Fc| 
u ■- argminjiT^i^^ 11 ^ 2,1 - |Fs|| 

L := L U ma.x{Fy,, Fu} 

F:=F-{F^U Fa) 

return L. 

Fig. 3. Pseudo-code of MaxPureDecompose algorithm 

Unlike the first variant, MaxPureDecompose needn’t compute the total clause 
size 1^1 each literal x. So it should run faster than the first variant. 

In order to ensure that is still very fast even if the number of variables is very 
large, the number 7 of variables for finding a literal with the highest occur¬ 
rence is limited to 5000 when n < 800000, 500 otherwise. In other words, in 
the actual implementation, the computation of m in Fig. 3 is replaced with 
m = max 2 ,<„/\s<x<s-i -7 max{|F!j:|, lAsI}, where s is the previous literal u with the 
highest occurrence. The decomposition quality of this algorithm is superior to 
that of the other algorithms on some application instances such as complete-500. 

3.4 A Simple and Limited BCE 

BCE is applied not only to BCD, but also to CNF preprocessing. Using a good 
BCE is very important. To improve the efficiency of LessInterfereDecompose 
that will be given in the next subsection, in Fig. 4 we present a simple and 
efficient BCE, which is different from that presented in [5]. BCE in [5] is based 
on a literal-based priority queue, while our BCE is based on a clause-based linear 
linked list. Another important difference from the usual BCE is that we do not 
try to test whether each literal / in C is a blocking literal when 1^1 > 300000. We 
test only literal I with |F^| < 2. That is, we replace the statement “ for I G C do 
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” in the usual BCE with the statement “ for I £ C with (|F^| < 2 or |F| < 300000 
or isFirst) do” , where isFirst is a Boolean variable for testing whether BCE is 
invoked for the first time. If it is the first time to call to BCE, we run the usual 
BCE. The condition “|F^| < 2” will not prevent forever from calling to BCE, 
since we select always literal I with the minimum occurrences, and move at least 
one clause from Fj to R every time, i.e., |Ey| decreases constantly. 

In the decomposition algorithm given in the next subsection, using this simple 
BCE is much faster than the usual BCE. Surprisingly, the decomposition quality 
keep unchanged in most cases. Even if it is changed, its change is still very small. 
In addition, our touch function is different from that in . Here is our definition 
about it. 


( Fx |E| < 800000 or isFirst 

touch{C,F) = h^^^j F, otherwise 

I x6CA|F„|<2 

When |F| > 800000, and it is not the first call to BCE, we consider only the 
clauses touched by the negation of literals with the number of occurrences < 2. 
This can speed up the decomposition of large instances. For example, using 
the above touch, the runtime required by LessInterfereDecompose to decompose 
q_query_3-L90 can be reduced from 600 seconds to less than 9 seconds. The 
decomposition quality keep unchanged still. 

^^^(touched clauses T, formula F, blocked set L) 
for each clause C € T A F do 

for I £ C with (|Ff| < 2 or |F| < 300000 or isFirst) do 

if all resolvents of C on Z are tautologies, i.e., C is blocked then 
L — LuiC} 

F ■.= F-{C} 

T := T U touch{C, F) 
continue with next C in outer loop 
return L 

Fig. 4. Pseudo-code of BCE algorithm 


3.5 Less Interfere Decomposition 

The two variants of PureDecompose both are based on the variable elimina¬ 
tion order. Nevertheless, in fact, it is difficult to find out the optimal algorithm 
by optimizing only the variable elimination order. Therefore, it is necessary to 
find a different decomposition technique. Below we present a new algorithm 
called less interfere decomposition, which is based on the order of clause elim¬ 
ination. Fig. 5 shows its pseudo-code. The basic outline of this algorithm may 
be sketched as follows: move blocked clauses in F to L by BCE, compute the 
candidate set S, move each clause C G S' fl F to F. These steps are repeated 
until F is empty. The computation of the candidate set S is based on the no¬ 
tion of interfering degree. The interfering degree of a clause C can be defined as 
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^ Ntaut{C'0iC), where Ntaut{X) is zero if X is a tautology clause, 
C'GF/\l&CAleC' 

and one otherwise. The probability that C'®iC is not a tautology clause is very 
high. To save the computing cost, we may approximate the interfering degree as 

X] \{l \ I & C /\ I € C'}\. LessInterfereDecompose in Fig. 5 uses this approxi- 
C'€F 

mation version to compute the interfering degree, and call this measure score, 

i.e., score[C] = ^ \{l \ I G C Al £ C'}\. To get clauses with the maximum 
C’eF 

score, all the clauses in F are traversed. If only one clause with the maximum 
score is moved to R from F each time F is traversed, it is time consuming. So 
we decide to move p clauses to R one time, where p = ^, where 6* is a constant. 
Table 1 shows the performance behavior for different 0’s on ACG-20-5pl with 
\F\ = 1416850. For this instance, selecting 400 as the value of 0 is a better choice. 
However, considering the other instances, actually for application instances, 0 is 
set to 200 when iTj > 8 x 10®, 2300 Otherwise. For large instances, because we 
put great stock in speed, 0 is selected as a smaller value. For small instances, 
because we put great stock in quality, 0 is selected as a larger value. This is 
actually a compromise between speed and quality. For random instances, 0 is 
set to 400 in any case. When < 18, p is set to 18. As shown in Fig. 5, the 
clauses with the first p highest scores are stored in S as the candidate clauses to 
be moved to R. In order to save time further, we compute the interfering degree 
produced by only literals with the lowest occurrence, not all literals. 

Lessinter f ereDecompose{F) 

L--R--S:=^ 

BCE{F, F, L) 

while F 7 ^ 0 do 
if S'nF = 0then 

m = min3,g,it(jr) |F„| 

for each clause C G Fdo 

for each clause e G Fi with I G C and \Fi\ = m do 
score[e] := score[e] + 1 

S := {a;|score[a;] > a, where the p-th highest score is a} 
select a clause C G S F 
F — F-IC} 

BCE{touch{C,F),F,L) 

return L 

Fig. 5. Pseudo-code of LessInterfereDecompose algorithm 

The runtime of LessInterfereDecompose consists of three parts: BCE, com- 
puting scores and determining S's. The runtime of computing scores is 0{- —L) = 
0(01^1). If scores are given, determining a S can be done in a linear time in |F|, 
since there exist linear time algorithms for finding the p-th highest score m- 
The total runtime of computing scores plus determining S’s does not exceed 
O(0|F|). If the number of clauses touched by each clause does not exceed a 
constant S, where 6 is certainly smaller than the maximal number of literal oc¬ 
currences times the maximal size of clauses, i.e., max^jg/^qp) iFj,! x maxceF \C\. 


Table 1. Performance of LessInterfereDecompose + post-processing given in Fig. 7 for 
different O’s on ACG-20-5pl. Time is in seconds 


e 

Time 


L 

F 


50 

6.95 

79.66% 

100 

6.03 

78.87% 

200 

5.44 

79.11% 

400 

5.57 

79.32% 

800 

6.52 

79.31% 

1600 

8.62 

79.77% 

2400 

10.64 

79.78% 


The total time required by all BCE's is at most 0(i5|F|). Thus, the total runtime 
of LessInterfereDecompose is at most 0{{S + 0)|F"|). In practice, <5 is generally 
very small. Should S is very large, we can remove a part of touched clauses to 
reduce the time required by BCE to test whether a clause in the touch list is 
blocked, or limit the size of the touch list a small constant, say 2000. Using such 
a policy can guarantee that the time complexity of LessInterfereDecompose is 
linear in lUj. Compared with EagerMover in [3], the runtime of BCE in LessIn¬ 
terfereDecompose is smaller than that in EagerMover. EagerMover calls at least 
four times BCE on a subset with the size of 0.75|F|. All calls to BCE on each 
clause C in F can be viewed as a call to BCE on the whole F. Thus, the total 
runtime of BCE in LessInterfereDecompose corresponds to double the runtime 
of BCE on a F. As long as the runtime of computing scores and determining 
S's is smaller than the runtime of BCE on a F, LessInterfereDecompose should 
be faster than EagerMover. In fact, that is true. On some instances, the former 
are indeed faster than the latter. 

3.6 Right Set Guided Post-processing 

In general, the above algorithms do not achieve maximal blocked set decom¬ 
position. However, they can be improved further by post-processing. The post¬ 
processing often used is MoveBlockedClause algorithm shown in Fig. 7, which 
is to move blocked (with respect to the current L) clauses from R to L. We 
noted that even if this post-processing algorithm is applied, the decomposition 
quality can be improved still. For this reason, we present a new post-processing 
algorithm, called Right set guided decomposition, which is shown in Fig. 6. It is a 
simplified version of LessInterfereDecompose. Replacing S with R results in this 
algorithm. This algorithm requires that the right blocked set R must be given in 
advance. Hence, it is used generally as post-processing. It is faster than LessInter¬ 
fereDecompose, since it need not compute R. Its time complexity depends mainly 
on that of BCE. For some benchmarks, this algorithm can improve significantly 
their decomposition quality. For example, to decompose SAT_dat.k75-24-l-rule-3 
using MinPureDecompose, the fractions of the large subset (i.e., |^) with Rset- 
GuidedDecompose and without it are 83.9% and 69.9%, respectively. If replacing 
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MinPureDecompose with LessInterfereDecompose, their fractions are 87.8% and 
87.3%, respectively. RsetGuidedDecompose raises still the quality by 0.5%. How¬ 
ever, the speed difference among the three algorithms is big. On this instance, 
LessInterfereDecompose, RsetGuidedDecompose and MinPureDecompose spent 
25, 4 and 1 seconds, respectively. The slowest LessInterfereDecompose is not 
suitable for huge instances with ten millions of clauses. 

RsetGuidedDecompose(formu\a F, right set R) 

L ;=0 

BCE{F, F, L) 
while T % 0 do 

select a clause C G {Rn F) 

F ■.= F- {C} 

BCE{touch{C, E),F,L) 
return L 

Fig. 6. Pseudo-code of RsetGuidedDecompose algorithm 


3.7 Mix Decomposition 

MoveBlockedClause{\eft blocked set L, right set R) 
for each clause C G R do 

if BCE(L U {C}) = 0 then L:=LU {C} 
return L 

MixDecompose{formu\a F) 

Li PureDecompose{F) 

L 2 ~ MinPureDecompose{F) 

L 3 := MaxPureDecompose{F) 

L := max{Li, L2, is} 
if \F\ < 5 X 10® and \var{F)\ < 10® then 
L 4 ~ LessInterfereDecompose{F) 

L := max{L, L4} 

L ~ RsetGuidedDecompose{F, F — L) 

L MoveBlockedClause{L, F — L) 

return L 

Fig. 7 . Pseudo-code of MoveBlockedClause, MixDecompose algorithm 

In general, in advance we do not know which algorithm is the best. Because 
all the algorithms given in the previous subsections are very fast, and running 
them one after another does not lose much time, we can construct an algorithm 
with high speed and high performance by combining them. The detailed imple¬ 
mentation is shown in Fig. 7. We call this algorithm MixDecompose. Its basic 
idea is to take the maximum from three left sets outputted by three algorithms 
as the initial L first. If the formula to be decomposed is not large, say the 
number of clauses and variables is less than 5 x 10® and 10®, respectively, we 
invoke LessInterfereDecompose to get a larger L. Finally, we enlarge the size of 
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L by calling two post-processing algorithms: RsetGuidedDecompose and Move- 
BlockedClause. Like the usual post-processing, the task of MoveBlockedClause is 
to move blocked clauses from R to L. Notice, if F is large, say |F| > 10^, the 
last post-processing can be canceled to save the running time. 

According to whether both subsets can be solved by BCE, a blocked clause 
decomposition can be classified as symmetric or asymmetric. If yes, it is symmet¬ 
ric. If only one of the subsets can be solved by BCE, it is asymmetric. Clearly, 
our two variants of PureDecompose are symmetric. If blockable clauses (whose 
definition is given below) are allowed to move to L like EagerMover [4], that is, 
replacing MoveBlockedClause with the procedure MoveBlockableClause of Ea¬ 
gerMover, MixDecompose is asymmetric, since it cannot guarantee that the two 
subsets both can be solved by BCE. However, even if adopting the replacement, 
by our observation, on almost all application instances, it is still symmetric. 


4 Empirical Evaluation 

We evaluated the performance of each decomposition algorithm on the 297 in¬ 
stances from the application track of the SAT competition 2014, except for three 
huge ones: zfcp-2.8-u2-nh, esawn_uw3.debugged and post-cbmc-zfcp-2.8-u2. The 
reason why the three huge instances were removed is that there is not enough 
memory to solve them. All the algorithms were run under the following exper¬ 
imental platform: Intel Core 2 Quad Q6600 CPU with speed of 2.40GHz and 
2GB memory. Each tested algorithm is written in G. The source code of MixDe¬ 
compose is available at http://github.com/jingchaochen/MixBcd, 

This paper presented four decomposition algorithms. To understand more 
clearly the characteristic of each of them, we compared them experimentally. 
Empirical results reveal that except for 41 application instances listed in Ta¬ 
ble 2, on all the other ones, the quality of LessInterfereDecompose is superior to 
that of the other three algorithms: MinPureDecompose, PureDecompose, Max- 
PureDecompose. That is to say, there are 256 application instances where Less¬ 
InterfereDecompose is superior to the other three algorithms in terms of quality. 
However, due to limited space. Table 3 lists only a part of instances. In Table 2-4, 
|E| denotes the number of the clauses in formula F, where F is simplified by 
removing satisfied clauses, but contains unit clauses. To obtain such F, before 
calling each decomposition algorithm, we use the same unit decomposition policy 
given in [4] as EagerMover to preprocess the input formula. Golumn indicates 
the fraction of the large set. Golumn Time shows the runtime in seconds. 

Only from Table 2, MinPureDecompose seems to be less important than the 
others, since there are only two instances where it is better than the others. 
However, in fact, on some large instances, it is very important. Eor example, for 
9vliw-m_9stage-iq3-Cl-bl, it is very important, because on this instance, Less¬ 
InterfereDecompose is much slower than MinPureDecompose, but their quality 
difference is small, as shown in the last row of Table 3. In MixDecompose execu¬ 
tion, to save the runtime, we skip LessInterfereDecompose and adopt the best 
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result of the other algorithms (which may well be MinPureDecompose) when 
|i^| > 5 X 10®. 

To evaluate the performance of MixDecompose, we select very competitive 
PureDecompose+EagerMover {PureEager for short) [914] as our comparison ob¬ 
ject. Although QuickDecompose [3] was proposed recently also, we did not select 
it as as our comparison object, because QuickDecompose requires more time 
than EagerMover for many instances. 

The large set L obtained by PureEager contains blockable clauses in addition 
to blocked clauses. A clause C is said to be blockable w.r.t. a blocked set L if 
each literal I € C is not a blocking literal of any clause in L. The reason why 
blockable clauses are added to the blocked set is that they do not destroy the 
blocked property. That is, blocked sets containing blockable clauses are still 
satisfiable. To keep identical with the performance evaluation of PureEager, the 
large set L of our MixDecompose contains also blockable clauses. 

Tabled compares the performance of PureEager and MixDecompose on ap¬ 
plication instances and a random instance from the SAT competition 2014. Al¬ 
though we tested the two algorithms on 297 application instances, due to limited 
space and the fact that listing all yields a tedious feeling, Tabled lists only a 
part of representative results. As seen in Tabled, in terms of decomposition 
quality, MixDecompose outperforms completely PureEager. In terms of speed, 
the former is sometimes faster than the latter, and vice versa. MixDecompose 
was able to finish the decomposition on all SAT 2014 application benchmarks 
excluding three huge instances within 110 seconds. However, PureEager was not 
able to finish on some benchmarks such as 9vliw-m_9stage-iq3-ClJ)7 within 300 
seconds. 

Tables presents the outline of the performance of two algorithms on 297 
benchmarks from SAT Competition 2014 application track. The second column 
shows the average fraction of the large set. Column of best’ indicates the 
number of the best results obtained by an algorithm. Column of eq’ is the 
number of results equivalent to ones obtained by another algorithm. On 226 out 
of 297 benchmarks, the size of the large set obtained by MixDecompose is larger 
than that obtained by PureEager. On 71 remaining benchmarks, the quality of 
the two algorithms is identical. There is no application formula where the qual¬ 
ity of PureEager is better than MixDecompose. In addition, we conducted also 
experiments on random benchmarks. We observed that on all random instances, 
the quality of MixDecompose is strictly better than that of PureEager. As seen 
from the last row of Tabled, MixDecompose can solve huge random instances 
with millions of clauses in a reasonable time. For 3-SAT random instances, it 
can increase the fraction of the large set by 5%. 

The fifth column in Table 5 shows the average runtime taken by each al¬ 
gorithm in seconds. Here, computing the average runtime counts only solved 
instances, excluding timed-out instances. The last column in Table 5, lists the 
number of times the time-out was hit. The timeout for each algorithm was set to 
300 seconds. MixDecompose did not time out on the tested benchmarks, while 
PureEager did on 7 benchmarks. MixDecompose took at most 110 seconds. Al- 
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Table 2. All application instances where LessInterfereDecompose {Lessinterfere for 
short) is inferior to the other three algorithms:MinPureDecx)mpose {MinPure for short), 
PureDecompose, MaxPureDecompose (MaxPure for short). Time is in seconds. 


Instances 

\F\ 

1 MinPure 

1 PureDecompose 

1 MaxPure 

1 Lessinterfere 

lO'i 


Time 


Time 

li^l 

Time 


Time 

ctL3791_556_nnsat 

8 

93.1% 

0.14 

88.9% 

0.01 

75.3% 

0.03 

88.1% 

3.17 

ctl_4291 _567_5_nnsat 

13 

87.6% 

0.66 

83.7% 

0.01 

68.6% 

0.04 

80.3% 

9.94 

atco_encl_opt2_20_12 

653 

78.5% 

1.48 

82.9% 

0.51 

77.3% 

1.47 

80.3% 

57.7 

atco_enc2_opt 1 _20_11 

971 

84.2% 

2.34 

87.0% 

0.86 

82.7% 

3.75 

86.0% 

64.2 

atco_enc2_opt2_20_ll 

651 

78.7% 

1.40 

83.0% 

0.50 

77.3% 

1.46 

80.4% 

58.1 

atco_enc3_opt 1 _03_53 

427 

51.0% 

6.61 

75.8% 

0.74 

75.4% 

12.9 

60.5% 

35.2 

atco_enc3_optl_04_50 

561 

50.5% 

8.90 

75.1% 

1.01 

75.0% 

21.9 

56.9% 

60.2 

atco_enc3_optl_13_48 

608 

50.5% 

9.92 

75.1% 

1.12 

75.0% 

22.8 

56.9% 

70.4 

atco_enc3_opt2_05_21 

538 

50.8% 

8.63 

75.8% 

1.02 

75.7% 

21.3 

57.8% 

55.2 

grien-vmpc-31 

15 

79.7% 

0.03 

79.8% 

0.01 

79.7% 

0.01 

79.7% 

4.60 

openstack-p30_3.085 

141 

76.7% 

0.52 

92.8% 

0.10 

85.1% 

0.13 

89.6% 

2.04 

openstack-s-p30_3.085 

141 

76.7% 

0.51 

92.8% 

0.11 

85.1% 

0.14 

89.6% 

2.03 

reg_s_2_unknown 

170 

77.0% 

1.17 

79.4% 

0.16 

69.0% 

1.22 

72.3% 

101 

vmpc_29 

12 

79.6% 

0.01 

79.7% 

0.01 

79.6% 

0.01 

79.6% 

4.17 

vmpc_32 

16 

79.6% 

0.02 

79.7% 

0.01 

79.6% 

0.01 

79.6% 

5.59 

vmpc_33 

18 

79.6% 

0.04 

79.7% 

0.01 

79.6% 

0.01 

79.6% 

6.81 

atco_enc3_opt2_10_12 

422 

50.3% 

6.61 

75.0% 

0.77 

75.1% 

14.2 

60.0% 

35.7 

atco_enc3_opt2_10_14 

423 

50.3% 

6.64 

75.0% 

0.78 

75.1% 

14.2 

60.0% 

36.1 

atco_enc3_opt2_18_44 

457 

50.3% 

7.22 

75.0% 

0.79 

75.1% 

14.5 

60.0% 

41.8 

complete-300-0.1-18 

3 

90.2% 

0.01 

90.0% 

0.01 

93.8% 

0.01 

90.8% 

0.79 

complete-300-0.1-4 

3 

90.8% 

0.01 

89.3% 

0.01 

92.9% 

0.01 

90.4% 

0.72 

complete-300-0.1-7 

3 

90.2% 

0.01 

89.8% 

0.01 

93.5% 

0.01 

90.8% 

0.81 

complete-300-0.1-8 

3 

90.8% 

0.01 

90.2% 

0.01 

93.0% 

0.01 

90.6% 

0.71 

complete-400-0.1-12 

5 

92.8% 

0.01 

91.6% 

0.01 

94.6% 

0.01 

92.0% 

2.70 

complete-400-0.1-16 

5 

91.5% 

0.01 

91.7% 

0.02 

94.5% 

0.01 

92.8% 

2.71 

complete-400-0.1-3 

5 

91.9% 

0.01 

92.0% 

0.02 

94.7% 

0.01 

91.8% 

2.65 

complete-400-0.1-7 

5 

91.7% 

0.02 

91.3% 

0.01 

94.6% 

0.01 

92.1% 

2.61 

complete-500-0.1-1 

7 

92.9% 

0.03 

93.0% 

0.03 

95.5% 

0.01 

93.3% 

1.97 

complete-500-0.1-15 

7 

92.7% 

0.03 

93.3% 

0.03 

95.5% 

0.01 

92.6% 

2.11 

complete-500-0.1-17 

7 

93.3% 

0.04 

93.1% 

0.04 

95.6% 

0.01 

92.8% 

2.08 

complete-500-0.1-7 

7 

93.2% 

0.02 

93.1% 

0.03 

95.6% 

0.01 

93.3% 

2.01 

complete-500-0.1-8 

7 

93.5% 

0.03 

92.8% 

0.02 

95.7% 

0.01 

93.3% 

1.98 

pb_300.10.1b_07 

55 

58.0% 

0.70 

64.7% 

0.02 

75.5% 

0.10 

71.0% 

15.1 

pb_300_10_lb_08 

56 

58.0% 

0.71 

64.7% 

0.04 

75.5% 

0.09 

70.6% 

15.3 

stable-300-0.1-20 

2 

88.9% 

0.01 

89.6% 

0.01 

93.3% 

0.01 

87.1% 

0.52 

stable-400-0.1-11 

3 

90.5% 

0.01 

91.8% 

0.01 

94.4% 

0.01 

89.8% 

1.51 

stable-400-0.1-12 

3 

91.2% 

0.02 

90.4% 

0.01 

94.1% 

0.01 

89.2% 

1.60 

stable-400-0.1-2 

3 

90.6% 

0.01 

90.5% 

0.01 

94.3% 

0.01 

88.9% 

1.59 

stable-400-0.1-4 

3 

90.3% 

0.01 

91.2% 

0.01 

94.3% 

0.01 

89.1% 

1.63 

stable-400-0.1-5 

3 

89.5% 

0.01 

91.6% 

0.01 

94.1% 

0.01 

88.7% 

1.61 

stable-400-0.1-7 

3 

89.7% 

0.02 

91.3% 

0.01 

94.3% 

0.01 

89.0% 

1.56 
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Table 3. Some application instances where the quality of LessInterfereDecom- 
pose{LessInterfere) is superior to that of the other three algorithms: MinPureDecom- 
pose (MinPure), PureDecompose, MaxPureDecompose (MaxPure). Time is in seconds. 


Instances 

\F\ 

1 MinPure 

1 PureDecompose 

1 MaxPure 

1 Lessinterfere 

104 


Time 


Time 


Time 


Time 

001-80-12 

31 

58.3% 

0.97 

57.7% 

0.03 

57.5% 

0.06 

99.2% 

6.05 

010-80-12 

31 

58.3% 

0.94 

57.7% 

0.04 

57.5% 

0.05 

99.2% 

6.09 

6sl0 

10 

66.5% 

3.18 

63.0% 

0.01 

63.0% 

0.12 

99.9% 

0.07 

6sl23 

241 

63.4% 

4.99 

62.5% 

0.25 

60.6% 

0.17 

97.7% 

0.67 

7pipe_k 

75 

96.7% 

1.91 

96.0% 

0.12 

96.1% 

0.04 

99.9% 

9.68 

8pipe_k 

133 

97.2% 

1.58 

96.7% 

0.27 

96.7% 

0.09 

97.9% 

2.74 

9dlx_vliw_at_b_iq3 

97 

93.4% 

4.93 

92.7% 

0.12 

92.2% 

0.11 

96.7% 

1.21 

9dlx_vliw_at_b_iq9 

968 

95.1% 

3.52 

94.4% 

1.61 

94.3% 

3.26 

96.5% 

50.5 

ACG-15-lOpO 

92 

71.5% 

1.06 

71.8% 

0.12 

68.7% 

2.16 

76.3% 

1.93 

aes_24_4_keyfind_4 

1 

54.4% 

0.01 

54.3% 

0.01 

55.1% 

0.01 

66.9% 

0.21 

aes_64_l_keyfind_l 

0.3 

52.8% 

0.01 

56.1% 

0.01 

50.7% 

0.01 

89.2% 

0.01 

AProVE07-01 

2 

61.3% 

0.30 

61.1% 

0.01 

61.1% 

0.01 

96.5% 

0.01 

AProVE09-06 

26 

62.2% 

0.57 

62.2% 

0.02 

62.2% 

0.23 

99.9% 

0.16 

atco_encl _opt 1 _04_32 

55 

69.4% 

3.08 

70.7% 

0.04 

69.5% 

0.21 

76.3% 

44.3 

beempgsol2bl 

8 

65.8% 

2.10 

62.6% 

0.11 

63.1% 

0.09 

99.9% 

0.30 

bjrb07ambal0andenv 

59 

66.7% 

1.31 

66.4% 

0.08 

66.3% 

0.94 

99.9% 

4.79 

blocks-blocks-37-1.130 

728 

88.6% 

1.88 

90.6% 

0.60 

87.4% 

5.25 

94.4% 

9.16 

bobl2m04 

168 

66.7% 

3.64 

60.9% 

0.17 

61.5% 

3.12 

99.9% 

2.74 

clObiJ 

40 

66.7% 

0.99 

62.1% 

0.03 

62.0% 

0.41 

99.9% 

0.92 

countbitssrl032 

6 

66.7% 

1.81 

58.5% 

0.01 

62.7% 

0.06 

99.9% 

0.20 

dated-lO-ll-u 

48 

69.4% 

0.42 

68.2% 

0.05 

62.1% 

1.05 

81.4% 

2.60 

dimacs 

1 

58.7% 

0.01 

58.9% 

0.01 

59.0% 

0.01 

99.9% 

0.01 

E02F22 

130 

99.0% 

1.35 

98.8% 

0.29 

98.2% 

0.12 

99.9% 

28.6 

grid-strips-grid-v-3.065 

350 

87.1% 

0.68 

85.8% 

0.29 

90.5% 

0.28 

97.1% 

1.77 

gss-25-slOO 

10 

65.0% 

3.01 

64.8% 

0.01 

64.6% 

0.17 

99.8% 

0.04 

hitag2-8-60-0-47 

3 

53.8% 

0.30 

52.1% 

0.01 

53.3% 

0.01 

98.4% 

0.53 

hwmccl0-k45-pdts3p02 

49 

66.7% 

1.09 

65.2% 

0.04 

64.8% 

0.71 

99.9% 

0.25 

itox_vcll30 

44 

54.3% 

0.71 

54.9% 

0.03 

54.7% 

0.78 

97.5% 

1.34 

k2fix_gr_rcs_w9.shuffled 

31 

99.6% 

0.26 

99.6% 

0.06 

99.6% 

0.01 

99.7% 

0.23 

korf-17 

9 

92.9% 

0.22 

93.0% 

0.01 

90.5% 

0.04 

99.5% 

0.16 

manol-pipe-clOnidw 

129 

66.7% 

3.11 

61.9% 

0.14 

61.7% 

1.43 

99.9% 

0.41 

maxxor032 

4 

66.6% 

1.06 

60.9% 

0.01 

60.8% 

0.20 

99.9% 

0.04 

MD5-32-1 

7 

56.6% 

0.34 

51.5% 

0.01 

53.3% 

0.01 

99.0% 

0.26 

minandmaxor 128 

75 

66.7% 

1.61 

62.1% 

0.07 

62.1% 

0.48 

99.9% 

3.14 

partial-lO-17-s 

118 

70.5% 

1.05 

69.0% 

0.14 

63.2% 

3.62 

78.3% 

2.48 

post-c32s-ss-8 

14 

62.7% 

4.06 

58.3% 

0.01 

57.9% 

0.15 

96.2% 

0.03 

rpoc_xits_15_SAT 

18 

97.9% 

0.03 

98.8% 

0.01 

97.6% 

0.01 

99.6% 

0.16 

SAT _dat.k90.debugged 

509 

70.6% 

8.66 

68.9% 

0.53 

68.8% 

8.71 

87.5% 

18.3 

slp-synthesis-aes-top28 

27 

64.3% 

0.53 

64.2% 

0.01 

64.2% 

0.23 

98.7% 

0.10 

velev-vliw-uns-2.0-uq5 

247 

94.2% 

0.85 

93.5% 

0.35 

93.2% 

0.18 

96.5% 

4.18 

9vliw_m_9s_iq3_C 1 _b 1 

1338 

86.0% 

4.13 

82.3% 

2.27 

82.4% 

1.58 

86.6% 

266 





















14 


Table 4. We run PureEager and MixDecompose on 297 application instances. Due to 
limited space and the fact that listing all is tedious, we list results on only a part of 
application ones and a random instance in the last row. Time is in seconds. 


Instances 

1^1 

1 PureEager 

1 MixDecompose \ 

104 


Time 


Time 

002-23-96 

13 

97.7% 

1.4 

99.3% 

0.29 

aes_24_4_keyfind_4 

1 

57.5% 

0.02 

68% 

0.11 

atco_encl _opt 1 _03_56 

26 

79.3% 

0.43 

83.5% 

7.89 

blocks-blocks-36-0.120 

607 

92.3% 

17.4 

96.4% 

12.65 

complete-500-0.1-17 

8 

93.9% 

2.2 

96.4% 

3.04 

dated-lO-ll-u 

49 

81.6% 

1.43 

82.6% 

2.91 

dimacs 

1 

99.9% 

0.14 

99.9% 

0.04 

grid-strips-grid-y-3.035 

167 

85.1% 

5.61 

95.1% 

4.18 

hitag2-7-60-0-80 

3 

73.8% 

0.26 

98.4% 

1.02 

MD5-29-3 

7 

81.4% 

0.29 

99.3% 

0.51 

openstacks-p30_3.085 

141 

93.5% 

1.73 

94% 

3.62 

partial-5-17-s 

101 

74.5% 

2.3 

82.1% 

5.66 

q_query_3JL150_coli.sat 

217 

67.9% 

52.4 

85.8% 

12.03 

q_query_3_L90_coli.sat 

118 

67.8% 

15.5 

88.1% 

9.04 

9vliw_m_9stage_iq3_Cl_b7 

1338 


> 300 

86.8% 

108.8 

9vliw_m_9stage_iq3_Cl_b4 

1335 


> 300 

86.7% 

109.2 

9dlx_vliw_at_b_iq6 

364 

95.2% 

14.7 

96.6% 

12.05 

SAT_dat.k75-24_l_rule_3 

415 

78.9% 

14.4 

87.8% 

33.83 

transport-35node- 1000s-4d 

590 

92.5% 

24.4 

92.9% 

15.66 

7pipe_k 

75 

0.97.0% 

1.92 

99.9% 

11.75 

ACG-15-lOpl 

94 

76.4% 

3.34 

79.6% 

7.07 

ctl_3791 _556_unsat 

8 

89.0% 

0.22 

93.6 

3.43 

korf-18 

19 

99.3% 

3.61 

99.7% 

10.79 

E02F22 

130 

99.6% 

125.8 

99.9% 

30.92 

MD5-30-4 

7 

86.1% 

0.46 

99.3% 

0.83 

partial-10-lTs 

68 

74.6% 

1.99 

83.1% 

4.78 

rbcl_xits_08_UNSAT 

7 

99.7% 

0.17 

99.8% 

0.12 

stable-400-0.1-4 

3 

91.2% 

0.49 

94.4% 

3.89 

total-lO-13-u 

79 

80.9% 

2.94 

81.9% 


UCG-15-lOpO 

79 

71.0% 

3.38 

78.0% 

5.76 

UR-20-10pl 

113 

70.6% 

4.84 

76.3% 

7.85 

UTI-20-5pl 

99 

70.6% 

4.24 

76.5% 

13.9 

vele V- vli w- uns- 4.0- 9-i 1 

323 

81.3% 

34.29 

86.5% 


IBM_FV.2004_SAT_dat.k40 

18 

91.9% 

0.83 

96.4% 

4.22 

unif-k3-r3.96-vl000000-c3960000 

S8043316035928452744 

396 

76.3% 

37.96 

83.2% 

82.18 


Table 5. Comparing performance of two algorithms on 297 benchmarks from SAT 
Competition 2014 application track. 
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though on average, PureEager run faster than MixDecompose, in this exper¬ 
iment, the worst-case runtime of the former was significantly lager than the 
latter. 

5 Conclusions and Future Work 

In this paper, we developed a new blocked clause decomposition algorithm by 
combining several decomposition strategies. The new algorithm not only achieves 
high quality decomposition, but also is fast. Even for large instances, it can en¬ 
sure that the decomposition is done within 110 seconds on our machine. Because 
our machine is slower than the platform of SAT competition 2014, If running on 
the latter, the speed will be more fast. 

In designing the blocked clause decomposition algorithm, we simplified Blocked 
Clause Elimination (BCE) by applying various cut-off heuristics, such as only 
’’touching” the literals with few occurrences. We believe that the simple and 
limited BCD may be also applied to improve the performance of BCE for CNF 
preprocessing, without sacrificing much the quality of the final result. 

So far we know only that we can get a higher quality decomposition than 
the existing algorithms such as PureEager. However, this does not mean that 
MixDecompose is the best. How to develop a better and more efficient than 
MixDecompose will be a fnture research topic. 
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